WMBUS extension to dispatch messages - old discussion #1248

HomeAutoUser · 2024-04-03T18:40:29Z

Please check if the PR fulfills these requirements

Tests for the changes have been added / modified (needed for for bug fixes / features)
commandref has been added / updated (needed for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Bugfix (please link issue)
Feature enhancement
(no DISPATCH from WMBUS Msg´s - Software extension for WMBUS #1247)
Documentation update
Unittest enhancement
other

What is the current behavior?
(You can also link to an open issue here, if this describes the current behavior)
-- no dispatch
What is the new behavior (if this is a feature change)?
-- you can dispatch a WMBUS message to clientmodule
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Other information:
-- in order to receive messages yourself, the firmware must be adapted (later step)

* added WMBUS definitions (register settings are not sufficient for reception)

* added WMBUS extensions to process messages

…into master_WMBUS

* message for documentation

RFD-FHEM#1247

…into master_WMBUS

sidey79 · 2024-04-03T19:45:28Z

FHEM/00_SIGNALduino.pm

-
+
+  my $mark;
+  if (substr($rmsg,5,1) eq 'Y') { # WMBus


Ich verstehe grob, warum das Y hier entfernt wird.
Was ich aber nicht verstanden habe ist, wieso die Daten mit Y und nicht MN im Modul ankommen.
Gerade auch, weil die FW ja noch angepasst werden muss.

MIST falsche Nachricht gelöscht :-(

Was ich aber nicht verstanden habe ist, wieso die Daten mit Y und nicht MN im Modul ankommen.
Gerade auch, weil die FW ja noch angepasst werden muss.

Ich schreibe nochmal "nur" kurz die Antwort.
Das mit dem Y wird aus der Historie und der Vielfahlt des WMBus Protokolles entstanden sein.
Wegen der Kompatiblität müsste es so beibehalten bleiben weil es so der CUL empfängt.

CUL_RAWMSG | bY25442D2C628346771B168D20BE124C0E20D48C96EA64C8FCCC14A07A3A8840A30DE4F084AB8D80F7 or CUL_868Mhz_RAWMSG | b3E44F536892656000108F5D97AAC0020256B755DD9228B433D8D5C82F0618CAD0643C2E540A722C2DC9B8A0138CE0041A2DCD11DE10F800C0001090086B41E0098DB14011E070416C580 or signalGateway_DMSG | b3E44F536892656000108F5D97AA9002025FB7AD4DF8710D69A3867E687B0633B1515F7BA8A6BE0C93649EC5593F476E7DD3E82F0470F800C0001090086B41E0098CE14011E070416C50018 signalGateway_Protocol_ID | 134 signalGateway_RAWMSG | MN;D=3E44F536892656000108F5D97AA9002025FB7AD4DF8710D69A3867E687B0633B1515F7BA8A6BE0C93649EC5593F476E7DD3E82F0470F800C0001090086B41E0098CE14011E070416C50018;R=24;A=0; or signalGateway_DMSG | bY304497264202231800087A5E0020A5D9CF9E719E36DB255C06F2AEC0722FC3853A3031BD85EF085BDAD29194136A02DD7E00FD signalGateway_Protocol_ID | 134 signalGateway_RAWMSG | MN;D=304497264202231800087A5E0020A5D9CF9E719E36DB255C06F2AEC0722FC3853A3031BD85EF085BDAD29194136A02DD7E00FD;R=253;A=0;

Hmm, das leuchtet mir noch nicht ein.
Das logische Modul braucht die Daten wie sie auch das CUL Modul übergibt.

Aber das SIGNALduino Modul braucht sie doch nur so, wie es der SIGNALduino übergibt.

Funktioniert beim IT Modul doch auch genau so.

Habe die RAW MSGs erst jetzt gesehen, aber wenn ich es richtig verstehe würde der SIGNALduino wie sonst auch

MN;D=304497264202231800087A5E0020A5D9CF9E719E36DB255C06F2AEC0722FC3853A3031BD85EF085BDAD29194136A02DD7E00FD;R=253;A=0;
übergeben.
Das bedeutet aber auch, dass hier nicht Y vom uC an das Modul übergeben wird, sondern der Y vom Modul an das logische Modul.. Richtig? In "SIGNALduino_Parse_MN" würde somit nie das gesuchte Y in der Variable rmsg ankommen.

Naja, wenn das Y vom Uc kommt, dann hätte ich vorgeschlagen die Regex anzupassen.
Den Teil der der an _limit_to_hex hätte ich mit einem substr von dem ersten Zeichen (das Y) entfernt.

Dann bleibt das Y in der rmsg enthalten.

Wäre aber schön, wenn wir einen Testdatensatz (rmsg) mit dem Y aufnehmen.
Die fehlt da und machte mich halt unsicher ob das vom uC so kommt.

Ich habe mal Euch etwas zusammengestellt @sidey79 & @elektron-bbs

-MSG1- uC_RAWMSG MN;D=Y304497264202231800087AE30020A5C247707714E518602D984FE2BF82C023288C39460740DC47132AAE42791B8F48F2EB00FD;R=253;A=0; Internal_DMSG bY304497264202231800087AE30020A5C247707714E518602D984FE2BF82C023288C39460740DC47132AAE42791B8F48F2EB00FD Internal_RAMSG MN;D=304497264202231800087AE30020A5C247707714E518602D984FE2BF82C023288C39460740DC47132AAE42791B8F48F2EB00FD;R=253;A=0 -MSG2- uC_RAWMSG MN;D=Y304497264202231800087AE40020A5D75DA00DA8A5A3E0E7A39CEFE3FA26FDC78E6C874675EFA951F6031F8E211C9E0BA500F7;R=247;A=0; HTML_RAWMSG (uninteressant für das SIGNALduino Projekt) Y304497264202231800087AE40020A5D75DA00DA8A5A3E0E7A39CEFE3FA26FDC78E6C874675EFA951F6031F8E211C9E0BA5 Internal_DMSG bY304497264202231800087AE40020A5D75DA00DA8A5A3E0E7A39CEFE3FA26FDC78E6C874675EFA951F6031F8E211C9E0BA500F7 Internal_RAMSG MN;D=304497264202231800087AE40020A5D75DA00DA8A5A3E0E7A39CEFE3FA26FDC78E6C874675EFA951F6031F8E211C9E0BA500F7;R=247;A=0;

Wie verfahren wir weiter oder wie gedenkst du @sidey79 solche Nachrichten an das entsprechende Modul weiterzugeben?

Was stört dich jetzt eigentlich an den Nachrichten?
Das einzige, was mir auffällt, ist das "Internal_RAMSG", das nicht der Nachricht vom µC entspricht.
Oder werden die Nachrichten etwa gar nicht an das WMBus-Modul weitergegeben?

Ich bin immer noch dafür, dass eine rmsg Einzug in die Testdaten erhält.
Dann können wir die Implementierung so anpassen, dass die Tests erfolgreich sind.

@sidey79

Ich bin immer noch dafür, dass eine rmsg Einzug in die Testdaten erhält.
Dann können wir die Implementierung so anpassen, dass die Tests erfolgreich sind.

https://github.com/RFD-FHEM/RFFHEM/pull/1248/files#diff-092416c5806fd44b768736cdcc4ed6b8b54b0c3f6123d65e96e3cc6f41b38c86R143-R174

@elektron-bbs

Oder werden die Nachrichten etwa gar nicht an das WMBus-Modul weitergegeben?
Doch diese werden an das Modul weitergegeben aber bei jeder _RMSG ist das Phänomen so.

* revised and clean

* adaptation tests due to WMBUS processing

codecov · 2024-04-04T17:10:31Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.92%. Comparing base (8bf9724) to head (52d0be7).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1248      +/-   ##
==========================================
- Coverage   89.13%   88.92%   -0.21%     
==========================================
  Files          43       43              
  Lines        2466     2466              
  Branches      170      170              
==========================================
- Hits         2198     2193       -5     
- Misses        114      119       +5     
  Partials      154      154

Flag	Coverage Δ
fhem	`88.92% <ø> (-0.21%)`	⬇️
modules	`88.92% <ø> (-0.21%)`	⬇️
perl	`88.92% <ø> (-0.21%)`	⬇️
unittests	`88.92% <ø> (-0.21%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

* added commandref

…into master_WMBUS

FHEM/00_SIGNALduino.pm

* revised datarate

HomeAutoUser · 2024-04-07T18:58:25Z

t/FHEM/00_SIGNALduino/01_SIGNALduino_Parse_MN.t

+        deviceName  => q[dummyDuino],
+        plan        => 2,
+        testname    => q[Good MN data, with RSSI, with set attribute rfmode=WMBus_T, DMSG started with bY],
+        input       => q[MN;D=304497264202231800087A5E0020A5D9CF9E719E36DB255C06F2AEC0722FC3853A3031BD85EF085BDAD29194136A02DD7E00FD;R=253;A=0;],


@sidey79 , diese MN Message ergibt eine DMSG mit bY. (Glaube ich, da ich den Kommentar so definierte)
PS: Genaue Daten habe ich erst morgen wieder am PC.

Es muss nach den Erklärungen doch auch eine RMSG mit MN;D=Y geben.

Es wird nun noch von Vorteil sein, bei diesen Warnings

2024-04-09T21:36:45.3459830Z 2024.04.09 21:36:39 4: dummyDuino: Parse_MN, Found 2-FSK Protocol id 108 -> Bresser 5in1 2024-04-09T21:36:45.3461571Z 2024.04.09 21:36:39 1: PERL WARNING: Illegal hexadecimal digit 'Y' ignored at FHEM/lib/SD_Protocols.pm line 1952. 2024-04-09T21:36:45.3483159Z 2024.04.09 21:36:39 4: dummyDuino: Parse_MN, Found 2-FSK Protocol id 117 -> Bresser 7in1 2024-04-09T21:36:45.3484865Z 2024.04.09 21:36:39 1: PERL WARNING: Illegal hexadecimal digit 'Y' ignored at FHEM/lib/SD_Protocols.pm line 2029. 2024-04-09T21:36:45.3505768Z 2024.04.09 21:36:39 4: dummyDuino: Parse_MN, Found 2-FSK Protocol id 131 -> Bresser lightning 2024-04-09T21:36:45.3508364Z 2024.04.09 21:36:39 1: PERL WARNING: Illegal hexadecimal digit 'Y' ignored at FHEM/lib/SD_Protocols.pm line 2052.

in der Datei SD_ProtocolData.pm jeweils bei der ID 108,117,131 den regexMatch => qr/^[a-fA-F0-9]+/, zu ergänzen. So würden doch die DMSG Nachrichten mit Y keinen Fehler produzieren. Oder sehe ich das verkehrt?

* revised Y processing

* added regexMatch for error prevention

HomeAutoUser · 2024-04-10T19:14:08Z

FHEM/00_SIGNALduino.pm

+  if (substr($rmsg,5,1) eq 'Y') { # WMBus frame type B
+    $rmsg1 = $rmsg;
+    $rmsg =~ s/^MN;D=Y/MN;D=/;
+    $mark = 'Y';
+  }


@sidey79 wir haben hier mal das RegEx eindeutig gestaltet um das Y zu entfernen. Die Zeichenkette MN;D=Y kommt nur einmal hervor in der RAWMSG und so kann es zu keiner Verwechslung kommen.

Zusätzlich haben wir mal intensiver nachgesehen weil dir das entfernen nicht so richtig zusagt.
Wir sind der Meinung, das wäre

aufwending

wiedersprichst du den Funktionsnamen (LimitHex)

erhöhst du ggf auch die Chance fehlerhafter Nachrichten verarbeitet zu werden.

Im Klartext:
Sobald du das Y in die Prüfungen einbauen möchtest, dann muss es an 3 Stellen (Routinen eingearbeitet werden was sehr arbeitsreich ist).

SIGNALduino_Parse_MN -> rmsg Prüfung

SIGNALduino_Split_Message Funktion (wird in SIGNALduino_Parse_MN aufgerufen)

_limit_to_hex Funktion (wird in SIGNALduino_Parse_MN aufgerufen)

_limit_to_hex Funktion (hier ein Y zuzulassen wäre gegen den Name HEX-Prüfung)

wir erhöhen somit auch die Chance, das "falsche MSGs" woanders verarbeitet werden könnten --> ggf. andere Fehler oder Warnings

Können wir dies so beibehalten wie von uns vorgeschlagen?

Ich denke da liegt ein Missverständnis vor.

Ich habe mir das ganz einfach vorgestellt.

Wie könnte ich das einfach bereitstellen.. hmm auf diesen PR kann ich ja keinen eigenen gescheit machen.

Wie könnte ich das einfach bereitstellen.. hmm auf diesen PR kann ich ja keinen eigenen gescheit machen.

Meinst du damit, keine Kopie des Branches um darin zu arbeiten oder etwas anderes?
Das könnte ich in das RFHEM Projekt duplizieren in einen separaten Branch

Können wir so machen, aber heute schaffe ich es nicht mehr.
Bin total fertig....

@sidey79 , du hast nun hier https://github.com/RFD-FHEM/RFFHEM/tree/master_WMBUS freie Hand ;-) um ggf deine Vorstellungen umzusetzen.

Ich habe es gepusht

Vielen Dank @sidey79.
Ich hoffe das Ganze richtig vereint zu haben hier, oder soll 7 wollen wir einen neuen PR von dem Branch, wo du geändert hast erstellen?

Wäre vermutlich die bessere Alternative, da dann auch der Codecover Report geht.

* create duplicate from https://github.com/HomeAutoUser/RFFHEM/tree/master_WMBUS for PR https://github.com/RFD-FHEM/RFFHEM/pull/1248/commits

HomeAutoUser and others added 14 commits April 3, 2024 19:57

Update SD_ProtocolData.pm

3a96ef5

* added WMBUS definitions (register settings are not sufficient for reception)

Automatic updated controls and CHANGED

d1441d2

Update 00_SIGNALduino.pm

5d2d7cd

* added WMBUS extensions to process messages

Merge branch 'master_WMBUS' of https://github.com/HomeAutoUser/RFFHEM …

45c5d49

…into master_WMBUS

Automatic updated controls and CHANGED

1cf7ee4

Update SD_ProtocolData.pm

80e8302

* message for documentation

Automatic updated controls and CHANGED

8dceb32

Update SD_ProtocolData.pm

47763c9

Automatic updated controls and CHANGED

c7b5240

Update SD_ProtocolData.pm

5f08ef9

RFD-FHEM#1247

Merge branch 'master_WMBUS' of https://github.com/HomeAutoUser/RFFHEM …

61a6aa2

…into master_WMBUS

Automatic updated controls and CHANGED

01f5b6a

Update 00_SIGNALduino.pm

f283954

Automatic updated controls and CHANGED

aa85d52

HomeAutoUser added the enhancement label Apr 3, 2024

HomeAutoUser assigned sidey79 Apr 3, 2024

sidey79 reviewed Apr 3, 2024

View reviewed changes

HomeAutoUser and others added 3 commits April 4, 2024 17:54

Update SD_ProtocolData.pm

8e8ba0d

* revised and clean

Automatic updated controls and CHANGED

52223c7

Update 01_SIGNALduino_Parse_MN.t

eb53980

* adaptation tests due to WMBUS processing

HomeAutoUser and others added 7 commits April 4, 2024 19:27

Update 00_SIGNALduino.pm

42779ae

Automatic updated controls and CHANGED

9ab9211

Update 00_SIGNALduino.pm

8d1ad82

* added commandref

Merge branch 'master_WMBUS' of https://github.com/HomeAutoUser/RFFHEM …

464ad88

…into master_WMBUS

Automatic updated controls and CHANGED

47e71ff

Update 01_SIGNALduino_Parse_MN.t

f1ab733

Merge branch 'master_WMBUS' of https://github.com/HomeAutoUser/RFFHEM …

269ceca

…into master_WMBUS

elektron-bbs requested changes Apr 4, 2024

View reviewed changes

FHEM/00_SIGNALduino.pm Outdated Show resolved Hide resolved

FHEM/00_SIGNALduino.pm Outdated Show resolved Hide resolved

revised

737ae79

* revised datarate

Automatic updated controls and CHANGED

595bfbd

elektron-bbs previously approved these changes Apr 7, 2024

View reviewed changes

HomeAutoUser commented Apr 7, 2024

View reviewed changes

Update 01_SIGNALduino_Parse_MN.t

0cfba47

HomeAutoUser dismissed elektron-bbs’s stale review via 0cfba47 April 9, 2024 21:35

HomeAutoUser and others added 6 commits April 10, 2024 20:58

Update 00_SIGNALduino.pm

382c06a

* revised Y processing

Automatic updated controls and CHANGED

ca35d6d

Update SD_ProtocolData.pm

dc82f48

* added regexMatch for error prevention

Automatic updated controls and CHANGED

c7eb93d

Merge remote-tracking branch 'upstream/master' into master_WMBUS

45eb012

Merge branch 'master' into master_WMBUS

a72db76

HomeAutoUser commented Apr 16, 2024

View reviewed changes

HomeAutoUser and others added 9 commits April 17, 2024 19:23

duplicate WMBUS proposal

1a981c7

* create duplicate from https://github.com/HomeAutoUser/RFFHEM/tree/master_WMBUS for PR https://github.com/RFD-FHEM/RFFHEM/pull/1248/commits

Automatic updated controls and CHANGED

a6b1f0f

feat[00_SIGNALduino]: Changed input validation for WMBus

098a189

Automatic updated controls and CHANGED

56899af

fix[00_SIGNALduino]: Removed unneded code

b16684d

Automatic updated controls and CHANGED

dc31cbc

Merge remote-tracking branch 'upstream/master_WMBUS' into master_WMBUS

8eb1ca5

Merge remote-tracking branch 'upstream/master_WMBUS' into master_WMBUS

e7f12e6

Automatic updated controls and CHANGED

52d0be7

HomeAutoUser changed the title ~~WMBUS extension to dispatch messages~~ WMBUS extension to dispatch messages - old discussion Apr 22, 2024

HomeAutoUser mentioned this pull request Apr 22, 2024

WMBUS extension to dispatch messages #1252

Merged

7 tasks

HomeAutoUser closed this Apr 22, 2024

HomeAutoUser deleted the master_WMBUS branch April 25, 2024 04:27

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WMBUS extension to dispatch messages - old discussion #1248

WMBUS extension to dispatch messages - old discussion #1248

HomeAutoUser commented Apr 3, 2024 •

edited

Loading

sidey79 Apr 3, 2024

HomeAutoUser Apr 4, 2024

HomeAutoUser Apr 4, 2024 •

edited

Loading

sidey79 Apr 4, 2024

sidey79 Apr 4, 2024

sidey79 Apr 8, 2024

HomeAutoUser Apr 9, 2024

elektron-bbs Apr 9, 2024

sidey79 Apr 9, 2024

HomeAutoUser Apr 9, 2024

codecov bot commented Apr 4, 2024 •

edited

Loading

HomeAutoUser Apr 7, 2024 •

edited

Loading

sidey79 Apr 7, 2024

HomeAutoUser Apr 9, 2024

HomeAutoUser Apr 10, 2024

sidey79 Apr 16, 2024

HomeAutoUser Apr 16, 2024

sidey79 Apr 16, 2024

HomeAutoUser Apr 17, 2024

sidey79 Apr 17, 2024

HomeAutoUser Apr 22, 2024

sidey79 Apr 22, 2024

WMBUS extension to dispatch messages - old discussion #1248

WMBUS extension to dispatch messages - old discussion #1248

Conversation

HomeAutoUser commented Apr 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HomeAutoUser Apr 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Apr 4, 2024 • edited Loading

Codecov Report

HomeAutoUser Apr 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HomeAutoUser commented Apr 3, 2024 •

edited

Loading

HomeAutoUser Apr 4, 2024 •

edited

Loading

codecov bot commented Apr 4, 2024 •

edited

Loading

HomeAutoUser Apr 7, 2024 •

edited

Loading